send queued messages in the background when the chat is not open - #41

* origin/main:
  polish home canvas widgets (#50)
  redesign shared and imported agent cards (#42)
  send queued messages in the background when the chat is not open (#41)

# Conflicts:
#	src/features/home/onboarding/starterHomeLayout.ts
#	src/features/home/stores/homeWidgetRuntime.ts
#	src/features/home/stores/homeWidgetStore.test.ts
#	src/features/home/stores/homeWidgetStore.ts
#	src/features/home/ui/HomeView.tsx

…hat's first turn

Starting a chat from the global composer could render the assistant reply
above the user message with its text doubled. At promotion two drains woke
at once: the chat store re-keys the queue to the backend id synchronously,
but the mounted ChatView is still registered as the foreground queue owner
under the renderer-local draft id until React commits the new `sessionId`.
The background drain saw the promoted queue as unowned, claimed the head,
and started `loadSessionMessages` — and because `loadingSessionIds` decides
per notification whether a turn is replay, the prompt the remounted
ChatView then dispatched had its whole live turn buffered as history,
merged with the replayed chunks by `messageId`, and finally written over
the transcript by `setMessages(sanitizeReplayMessages(buffer))`.

Two guards, either sufficient alone:

Honor the draft id as foreground ownership for a promoted session. A
promoted row keeps its renderer-local id as `clientSessionId`, so the
background drain now treats an owner registered under either id as the
claimant and the hand-off instant can no longer look unowned. The
foreground queue sends the head, as it did before PR #41 added this drain.

Claim the dispatch target before hydrating, not after, in
`acquireExistingSessionForBackgroundSend`. That publishes the window the
load opens: any other sender — a ChatView the user opens mid-hydration,
not just the promotion hand-off — sees contention and waits for the
release instead of dispatching into a load that will misclassify its
turn. Hydration under a held lease is already the pinned contract
(`sessionActivation.test.ts` leases a session across a divergent load),
so the target semantics are unchanged: a matching observation is absorbed
and a divergent one is deferred to release. The lease is released on every
failure path so a rejected load cannot leave a session looking busy.

Conforms to LAWS/CHAT.md: a message MUST NOT have more than one active
send attempt, and a session is ready only if it can accept a message — a
session whose history load is in flight cannot accept one live.

Still latent and out of scope: a prompt dispatched during a `session/load`
that no lease covers (an activation load racing a foreground drain) would
misroute the same way. Closing that needs queued-send readiness to gate on
`loadingSessionIds`, which changes readiness semantics for berdctl's
`--if-running` as well.

Signed-off-by: Matt Toohey <contact@matttoohey.com>